判決書只寫「綜合全案證據，被告有罪」不會有人接受，法官必須交代哪一句認定對應哪一份證據；/ask-vault 昨天做到的「附上引用清單」，就像只交代了「本案引用過哪些證據」，卻沒交代「哪一句話用了哪一份」。今天要把這件事補上，同時明文禁止「證據不足就用常識腦補」。

Day23 把 /ask-vault 的兩階段混合檢索流程定案：結構檢索先篩出候選筆記、語意理解只讀候選正文，最後回答結尾附上一份「本次回答實際引用到的筆記標題清單」。這份清單解決了「答案有沒有依據」的問題，但沒解決「答案的哪一句對應哪一篇依據」——使用者只能整篇答案打包相信，或整篇打包懷疑，無法逐句核對。更棘手的是，規格當時也沒有明文擋住一種情況：候選筆記正文其實答不完問題的某個部分時，Agent 該怎麼辦？沒有禁止事項，就有可能被訓練知識或常識悄悄補完，讓答案看起來完整、但其實有一部分完全沒有筆記依據。

逐句標註：行內寫標題，不做編號腳註

Day24 的第一件事，是把「回答附帶引用筆記標題清單」這個 Requirement 換成「回答附帶逐句可追溯的引用標註」：答案本文中每一句陳述句都要標明依據的候選筆記標題，例如以 （依據：《筆記標題》） 的行內文字標註在句子後面。

選擇行內標題而不是 [1]/[2] 編號腳註，是因為 /ask-vault 的輸出是終端機文字，編號需要讀者往回找結尾的對照表才能確認依據；行內直接寫標題，每句話當下就能核對，不需要額外的對照步驟。同一篇候選筆記支持的連續多句陳述，允許在段落末合併標註一次，不強制每句都重複完整標題文字——這是刻意留的排版彈性，避免逐句標註淪為「每句都貼一次同一個標題」的累贅格式，但前提仍是讀者要能明確判斷每句陳述對應哪一篇候選筆記。

防幻覺：不是拒答，是誠實標出「候選筆記未提及」

第二件事，是把既有的「答案內容只能根據第二階段實際讀取到的候選筆記正文」這條規則，明確擴充成一條可執行的禁止事項：若候選筆記正文合計不足以回答問題的某個部分，Agent 必須在答案中指出該部分「候選筆記未提及」，不得用訓練知識、一般常識或臆測填補。

這裡刻意不要求「整體拒答」。使用者的問題常常包含好幾個子問題或面向，候選筆記可能答得出其中一部分、對另一部分完全沒提到——整體拒答會讓已經有依據的部分也被浪費掉。逐部分標明「有依據的部分」與「候選筆記未提及的部分」，比一刀切的全有或全無更有用，也更符合 Day23 以來「限縮範圍要對使用者透明」的同一種設計語言：誠實揭露限制，而不是把限制藏起來。

這兩項變更完全建立在 Day23 定案的檢索流程之上——結構檢索、候選為零時的圖鄰居擴散、候選過多時的限縮排序，這三段規則一字未動，Day24 只動「候選筆記篩出之後，答案該怎麼寫」這一段。

實際跑一遍：同一組候選筆記，四種問法

沿用 Day23 demo vault 裡跟 Cobra 相關的 4 篇筆記（《Cobra CLI 框架》《選用 Cobra 作為 CLI 框架》《Cobra flag 綁定筆記》《Cobra 子指令樹筆記》），用四個問題重新驗證。

情境一：關鍵字直接命中，逐句標註 + 同筆記合併標註 ——問「vault 裡有哪些跟 Cobra 這個 CLI 框架相關的筆記？」，title 直接命中同一組 4 篇候選。答案本文示範如下（節錄）：

《選用 Cobra 作為 CLI 框架》這篇 ADR 的背景是 brain-cli 預期會持續新增子指令與旗標，手刻 os.Args 在指令變多後遲早要重構。決策是採用 github.com/spf13/cobra，取得子指令樹與 flag 綁定機制帶來的邊際成本穩定的好處，代價是必須讓貢獻者遵循 Cobra 的慣例（依據：《選用 Cobra 作為 CLI 框架》）。

這兩句陳述都來自同一篇 ADR，合併在段落末標註一次，讀者仍能明確判斷這兩句話的依據筆記，不需要往回對照結尾清單。

情境二：候選部分答得出、部分答不出，兩種標註並存 ——問「Cobra CLI 框架這篇筆記有沒有提到它的效能表現數據，以及目前專案使用的 Cobra 版本號是多少？」，候選一樣是同一組 4 篇。實際讀完正文後，這 4 篇都沒有提到效能數據或具體版本號，答案誠實回報：

候選筆記中，《Cobra CLI 框架》《選用 Cobra 作為 CLI 框架》《Cobra flag 綁定筆記》《Cobra 子指令樹筆記》都沒有提到 Cobra 的效能表現數據或專案實際使用的版本號，候選筆記未提及此部分。這 4 篇筆記能回答的是導入 Cobra 的原因與基本用法（依據：《Cobra CLI 框架》）、選用 Cobra 而非手刻 flag 套件的 ADR 決策背景（依據：《選用 Cobra 作為 CLI 框架》），但都沒有涉及效能數據或版本號，這部分無法從候選筆記得到答案。

沒有出現任何「Cobra 目前穩定版是 vX.X.X」之類看似合理、實際是訓練知識腦補的內容——這正是防幻覺規則要擋住的情況。

情境三：spf13 觸發圖鄰居擴散，檢索邏輯不受輸出格式變更影響 ——重跑 Day23 的第二個情境，問「vault 裡有沒有筆記提到 spf13/cobra 這個套件？」，第一階段候選為零，靠《Cobra CLI 框架》的 Frontmatter aliases: ["spf13/cobra"] 命中種子節點，沿圖擴散一層拿回同一組 4 篇候選。答案除了照常揭露「已沿 Wikilink 圖擴散一層鄰居筆記」，也同時示範逐句標註與「未提及」判斷混用：

《Cobra CLI 框架》明確寫出 github.com/spf13/cobra 是 Go 生態中最廣泛採用的 CLI 框架（依據：《Cobra CLI 框架》）。《選用 Cobra 作為 CLI 框架》這篇 ADR 也記錄了正式選用 github.com/spf13/cobra 的決策（依據：《選用 Cobra 作為 CLI 框架》）。另外兩篇《Cobra flag 綁定筆記》與《Cobra 子指令樹筆記》雖然也在候選清單中，但正文沒有直接提到 spf13/cobra 這個套件名稱，候選筆記未提及這部分。

情境四：完全找不到相關筆記 ——重跑「vault 裡有沒有討論量子糾纏演算法的筆記？」，種子節點依然找不到，直接回報「vault 中找不到相關筆記」並中止，不進入輸出格式的任何規則——證實這條路徑完全不受本次變更影響。

四個情境都確認了同一件事：Day23 的檢索邏輯（篩選、擴散、限縮）原封不動，改變的只有「候選筆記確定之後，答案怎麼寫」。

這篇還沒做、也不打算做的事

防幻覺規則仍然停留在「規格明文禁止 + Agent 自我檢查」的層級，沒有引入自動化的幻覺偵測工具或事實查核服務去強制校驗每一句答案是否真的能對應回筆記內容——/ask-vault 全系列（Day23-24）的目標是示範「結構化工具 + Agent 語意理解」的混合工作流程，而不是打造一套獨立的事實查核系統。同樣地，「候選筆記未提及」的判斷仍由 Agent 主觀認定，這與 Day23 候選篩選依賴 Agent 主觀判斷是同一種性質的既有 Trade-off，本篇選擇用規格明文要求誠實揭露來緩解，而不是另外引入程式化裁決機制。

至此 qa-retrieval capability 從「檢索流程可用」進化到「回答品質可信」：候選筆記怎麼篩、怎麼擴散、怎麼限縮（Day23）之上，疊加了逐句可追溯的引用格式與防幻覺的明文禁止（Day24）。下一篇會把 Stage 4（Day20-25）目前累積的 Graphify 匯出、樞紐/斷點判讀與 /ask-vault 混合檢索整合成一次完整示範。